需求分析方法论

一. 需求的获取、采集与表达

需求分析是产品经理的核心竞争力，以需求的来源、采集与描述三个方面为入口，结合案例，介绍了相对应的方法和使用工具。

从哪里获取需求？

需求的获取方式有很多，比如产品大牛的天马行空，用户粉丝的意见反馈，产品前期的用户调研等等，以下是几个常用的获取需求的方式。

1. 来源

1.1 用户调研

（1）定量调研-问卷
目的：根据调查者想要获取的信息设计问卷，收集一定基数并进行数据分析。
优点：结果便于统计处理与分析、可大规模的调查、效率高节省时间成本。
缺点：调查结果广而不深、问卷设计对用户选择有间接影响、开放性问题少、无法引导用户深入思考。

（2）定性调研-采访
目的：挖掘用户的主观因素，从宽度（体验、感受、困惑、预期）和深度（功能-结果-利益-价值观）两个维度判断他们对产品的认知。
优点：深入有效，多为开放性问题，可由浅入深得知受访者的需求，进而挖掘受访者的需要和痛点。
缺点：样本小、需要较多的人力、物力和时间、面对面缺乏隐秘性导致受访者回避敏感问题。

1.2 用户反馈

常见的用户反馈来自于互联网社交平台（微博、贴吧、知乎、微信、QQ、app store以及产品自带的客服投诉和建议模块。一般通过以下几条判断条件筛选出有用的反馈并加以解决相应问题：

（1）用户类型—什么用户提出的？（潜水用户／话题制造者／专业人士／死忠粉／VIP会员等）
一般专业人士提出的反馈结合了丰富的专业知识，比较有深度；死忠粉有长期使用产品的经验，对产品理解较深；VIP会员是产品的核心用户，及时解决他们的问题十分有必要。这些用户反馈的价值性相应高于一般或短期用户。

（2）使用场景—在什么场景下提出的反馈？（地铁／公司／学校／车上／上班时／吃饭时／睡觉前等）
根据用户使用场景的频率和次数判断，一般使用频率高的场景下提出的反馈可能是大部分用户都遇到的，所以解决此类问题的优先级相应较高。

（3）反馈次数—是否有同类型、重复的反馈？（单个用户多次反馈相同问题／多个用户反馈相同问题）
如果同一个用户多次反馈相同问题，说明此问题已经重度影响了该用户的用户体验，而且一直没有得到解决；反馈中一个问题被不同用户反复提起，说明大部分用户受到困扰，这两种情况下的反馈应优先被解决。

老板

在产品研发初期，经常会遇到会上老板一句话直接给需求，这些需求往往来自于老板丰富的工作经验以及敏锐的市场嗅觉，不能说老板提出的一定对，但是一定是有依据的。作为产品人员应该先消化和理解老板的想法，如果还是觉得有问题，拿出相应的数据依据来说服老板。

数据分析

一般来说，产品人员可以通过一些数据网站（极光数据、百度指数、艾瑞咨询）获取市场趋势和用户喜好，进而获取用户需求；此外，运营及数据分析专员

会根据市场做的相关数据统计（访问数、停留时间、跳出率等）提出部分需求。

需求采集步骤

不同的阶段需求采集可使用的方法也不一样，苏杰在《人人都是产品经理》一书提到，合理搭配定性和定量方法，一般可根据产品时间轴分为四部分：

产品规划阶段，针对性采访用户，定性分析用户需求，确定产品整体大方向
产品早期，投放问卷调研，定量分析用户需求，确认产品需求
产品上线阶段，测试并根据用户反馈获取需求，确认产品需求优先级
产品优化阶段，根据用户使用产品情况定量分析数据，确认需求优化产品

需求的构成

需求不是单独存在的个体，而是与场景、用户、目标同时出现的。当描述一个需求时，需要交代时间、地点、人物、描述、需求（欲望）和方法。举个简单的例子：

在一个阳光明媚的早晨（时间），我在去地铁站的路上（地点），但是距离有点远，走路要十五分钟（描述），于是我产生了一个快点到达地铁站的想法（欲望），决定扫描二维码，骑小黄车去地铁站（方法）。

这样描述起来需求会显得具体易懂，也有利于产品人员之后的需求表达和管理。

如何完整表达需求

在需求被采集之后，需要将各种需求具象化并放入需求池中，这里提供两种方法来表达需求，一个是单项需求卡片描述单个需求，另一个是需求清单（feature list）来管理多个需求。

1.单项需求卡片

此卡片的核心在于让开发人员了解每个需求的描述信息（who/where/what/when/why）以及重要紧急程度，为未经加工过的用户需求，多为需求属性陈述。下图为模版并详细解释了各个栏目要填写的内容：

以小黄车为例，近来看到网上讨论是否要在小黄车APP增加导航功能（事实上笔者认为此需求为伪需求），那么它的单项需求卡片卡片填写应该如下：

2.需求清单

单项需求卡片和需求清单不仅仅着重于表达需求，也涉及到部分需求管理内容。而且，面对随时都有可能蹦出来的需求，如何评估需求性价比并选择性纳入需求池也是产品经理需要考虑的，在下一部分需求管理中进行讲述。

二.需求分析的步骤

从事需求分析以来，不管是自己参与的或是完全由自己一个人需求调研的，也有过大大小小项目需求调研的经历。这周去了深圳某券商进行了为期一周的需求调研，需求调研完成之后，其实总结下来有些套路可以使用。

如果把IT比做一个江湖，无论是什么公司什么业务的需求，练好这个武功心法“四层五步五清法”，可以从宏观上以及部分微观上理解用户的需求。之所以说是部分微观，是因为具体的需求，还得具体的分析，但练好这个武功心法，在需求分析的宏观上可以说没有问题。

四层：

1.第一层职能层：梳理各部门的职能。

一个系统如果涉及到很多部门，那么梳理各部门的职能能帮助我们去理解他们提出需求的原因，甚至通过了解各部门的职能反过头去质疑其他部门提出的需求。

举一个很简单的例子，某券商的风控部牵头要建设信用风险管理系统，为实现监管的“同一客户，同一业务，统一管理”，风控部将其他业务部门也纳入到系统中来，在需求调研阶段，某业务部门提出在实现一个报表查询到时候，需要部门与部门的权限隔离，即固收部的看固收部的持仓数据，其他部门在看同一张报表的时候看不了固收部的持仓数据。

咋一听这个需求提的很合理，但是风控部的职能是从公司整体上控制风险并防范风险，风控部可以看所有业务部门的数据。

用户提需求的时候只是出于自身考虑，并没有想到其他部门，所以当需求涉及多个部门的时候，需求分析人员在需求调研阶段把各部门的职能弄清楚。

2. 第二层业务层：梳理业务。

没有人会无缘无故去购买一个系统，对于企业而言购买系统就是想将公司的业务放在系统上去做。不同类型的企业或不同部门，业务是不一样的，业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。

当一个业务小白如何快速的理解业务，可以搜集业务相关的名词解释，弄懂这些名词算四分之一理解业务。每种业务都会有其特定的术语，比如在物流行业，你需要知道什么是货代、邮路、头程、预报等等，在金融行业，你需要知道什么是股票质押、债券投资、融资融券、资管计划，除此还不够，你需要理解透每一个业务以及业务与业务的差别，比如股票质押与融资融券的差别在哪？

3. 第三层数据层：梳理信息。

这需要需求分析人员懂一些技术才能梳理清楚，对需求分析人员很高要求的一个层次。对于系统的底层数据，需要梳理数据与数据的流向，数据与数据的逻辑关系，这些都梳理清楚以后，对于现在的开发或是以后的迭代都能起到很大的作用。

4. 第四层：梳理支撑环境。

业务需求以及数据都弄清楚以后，还需要考虑非功能性的需求，比如系统的硬件环境和软件环境是什么，用谷歌浏览器还是IE浏览器等。

以上是四层五步法的四层，如何去实现上面的四层，做到以下“五步”：

根据组织结构梳理职能域，比如机构／部门的职能，各岗位的工作职责
根据职能域梳理业务元素，包括业务术语、名词解释等
根据业务元素梳理业务活动，如业务流程、业务环节、状态、信息等
根据业务活动梳理业务等内外联系，如业务协作、信息流向
描绘业务架构、信息架构，如用户分类、业务分类、信息分类

四层和五步做到以后，问自己几个问题，看看是否真正的理解需求：

业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。
业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。
业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。
业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件……
跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。

1-1 需求分析方法论